Computer and information networks such as the Internet enable computer systems to exchange streams of data such as audio data, video data, multimedia data or other streaming data between software applications running on different computer systems. As an example, a user controlling a web browser operating on a client computer system can select a hyperlink that corresponds to an audio stream data or audio file that an audio stream server computer system can serve to the client computer system over the Internet. In response to a selection of the hyperlink, the web browser can invoke an audio player software application that operates in conjunction with the web browser on the client computer system to play the audio file. Typically, an audio player software application can communicate with the audio stream server software application running on the audio stream computer system in order to establish an audio stream data connection between the client computer system and the audio server. Once such a connection is established, the audio stream server can begin serving or streaming the audio stream data back to the audio player software application operating on the client computer system. The audio player software application can then receive and play the audio data via speakers coupled to the client computer system for the enjoyment by the user.
Due to the real-time or near real-time nature of audio data, video data, multimedia data or other such data, the audio player software application and audio stream server software application may utilize one or more real-time or near real-time data transfer communication or control protocols in order to appropriately control the flow of streaming data from the stream server to the client computer system. An example of such a real-time data transfer communications or control protocol is the Real Time Streaming Protocol (RTSP). Other such protocols exist as well.
Generally, RTSP is an application-level protocol for controlling the delivery of data with real-time properties such as audio data, video data, and the like. RTSP provides a framework to establish and control one or more time-synchronized streams of continuous media such as audio and video stream data supplied from a stream server to a client computer system. RTSP messages do not ordinary deliver or carry the continuous streaming data itself, but rather operate as a set of out-of-band messages or requests exchanged between the client and a stream server to control and synchronize delivery of the streaming data. It is possible for RTSP to actually carry the streaming data on the same control connection. However, in an overwhelming majority of RTSP streaming data applications, streaming data is sent separately from control information. Thus, RTSP enables client computers to “remotely control” streaming data from multimedia servers.
According to the general operation of RTSP, the client and a stream server exchange RTSP requests in order to adjust the flow of stream data served from the stream server to the client. As an example, a client may send an RTSP “PLAY” request specifying an offset, play time, location or absolute position in the stream data at which to begin playing or serving the stream data. The stream server receives the RTSP PLAY request and begins serving the stream data at the requested play time. The server also sends a “200 OK” back to the client on the control connection, indicating that everything is alright and that the server will start sending the data stream. This response is sent on all control received by the sever from the client. In case of an error, the response will not be “200 OK” but will instead be a “400 bad request” or similar type of message. During receipt of the streaming data from the server, the client may wish to alter a transmission characteristic of the stream data such as, for example, to increase or decrease the bandwidth or rate at which the stream server serves the stream data, or to seek forward in the stream data to a desired offset (referred to as absolute positioning). For instance, the client may detect that the stream server needs to serve the streaming data at a higher bandwidth or rate in order for the client to be able to reproduce the stream data for the user in a realistic or real-time manner or at a better quality of service. In response, the client may send an RTSP message to increase the rate at which the stream server serves the streaming data. This RTSP message or request propagates through the network (i.e., through a series of one or more data communications devices such as switches and routers) to the stream server. The stream server adjusts the bandwidth or rate of streaming data from the server according to the RTSP bandwidth adjustment message. Bandwidth may be implemented as a method command (e.g., similar to “PLAY,” “PAUSE,” etc.) or alternatively bandwidth information may be included in a header of a method command.
As another example, if the user at the client computer desires to rapidly advance forward or backward in the data stream, the user may operate fast-forward or rewind buttons provided by the audio client software application (e.g., via a graphical user interface). Operating the fast forward or rewind buttons causes the client to issue one or more RTSP requests to the stream server, each RTSP request specifying a particular incremented offset or absolute position within the stream data at which the server is to begin serving the stream data. The offset or absolute positions are typically identified relative to the beginning of the stream data. Accordingly, if the user depresses and holds a “FAST FORWARD” graphical user interface button provided by the client receiving the stream data, the client will issue a series of RTSP play requests each containing successively incremented absolute position values. It is also possible for a client to issue just one request (or two requests) instead of a series of many commands to achieve this goal. Upon receipt of each of such RTSP play requests, the stream server begins serving stream data at the indicated absolute or relative position in the stream data until the next request is received to provide the appearance to the user of rapidly playing or advancing ahead into the streaming data.
For complete details on the operation of RTSP, the reader is directed to Request For Comment 2326 (RFC-2326) which is a document maintained by the Internet Engineering Task Force (IETF) that specifies an Internet standards track protocol for RTSP. The teaching and contents of the RFC-2326 document are hereby incorporated by reference herein in their entirety.
Other conventional data transfer communications protocols can carry out the processing and messaging required to carry or transport the actual stream data to a user. As an example, the Real Time Protocol (RTP) can be used as a transport mechanism to propagate real-time streaming data through a computer network. In general, the RTP protocol encodes real-time stream data into packets, each of which includes sequencing and/or timing information stored in virtual time fields. The timing information enables a recipient to identify how the portions of stream data in one RTP encoded packet relate to other portions of stream data in other RTP packets. Thus, RTP can encode data with timing information about the media to provide a reference to the recipient for how the media can be played back.